Method and apparatus for allowing software access to navigational data in a decrypted media stream while protecting stream payloads

ABSTRACT

A method, apparatus and system enabling software access to navigational data in a decrypted media stream while protecting stream payloads. In one embodiment, a filter may route an encrypted content stream and associated information to a secure partition having a trusted computing component for decryption. Upon decryption, the trusted computing component may store the decrypted payload of the content in a secure storage location accessible to the trusted computing component. Thereafter, the decrypted navigational header information of the content may be used to navigate to the decrypted content via a trusted component such as a trusted rendering unit in the secure partition.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 13/734,164, filed Jan. 4, 2013, entitled “METHOD AND APPARATUSFOR ALLOWING SOFTWARE ACCESS TO NAVIGATIONAL DATA IN A DECRYPTED MEDIASTREAM WHILE PROTECTING STREAM PAYLOADS,” which in turn is acontinuation of U.S. patent application Ser. No. 12/586,618, filed Sep.23, 2009, now U.S. Pat. No. 8,363,831, entitled “METHOD AND APPARATUSFOR ALLOWING SOFTWARE ACCESS TO NAVIGATIONAL DATA IN A DECRYPTED MEDIASTREAM WHILE PROTECTING STREAM PAYLOADS.” The foregoing are herebyincorporated by reference in their entireties.

BACKGROUND

As digital content transmissions continue to proliferate through variousaspects of day to day life, the issues surrounding protection of thecontent become increasingly important. Content may be transmitted toso-called “open” or “closed” platforms. A reference to an open or“untrusted” platform typically refers to a platform that places nosecurity restrictions on applications that may be installed on it. Atypical example of an open or untrusted platform is a personal computing(PC) device running Microsoft Windows. Any application written toconform to the Windows specification may be installed on the platform,without any regard to how safe the application may be. AlthoughMicrosoft has recently attempted to “close” the operating system, a PCrunning Microsoft Windows is still considered an open platform.

In contrast, closed platforms typically do not allow users to installarbitrary software. Examples of closed platforms include set top boxessuch as TiVO and Apple's iPhone. In the scenario of TiVO, noapplications may be installed on the device—it may simply receive,decrypt and render content. Similarly, although a variety of individualsand vendors may write applications that run on Apple's iPhone, only“approved” applications are made installable on the iPhone via Apple'sApp Store. Closed platforms thus have inherently built-in protectionagainst malicious applications because the applications are trusted,i.e., from an authorized source.

Regardless of the type of platform, media content is typically encryptedfor security purposes. Newer media formats and devices recognizediscretely encrypted content, i.e., content in which the payload itemsare discretely encrypted and the navigational headers of the mediastream are left unencrypted. As a result, regardless of whether it is anopen or closed platform, the navigational headers are accessible withoutdecryption and the encrypted payload portions can be decryptedindependently from each other and from the navigational headers.

In contrast, if the media content is monolithically encrypted as istypical for older media formats and devices, the navigational headersand payload of the content stream are typically encrypted en masse.Thus, on those devices, the platform is forced to decrypt the entirecontent stream in order to access the navigational headers and play thecontent. While this poses little to no risk on a closed platform whereall content and applications are presumed trusted, this scenario createsa significant security problem for untrusted platforms. One popularsolution to this issue is for content providers to encrypt only themedia payloads while leaving the header data in the clear. This allowsthe receiving device to access the headers for navigation purposes,while deferring payload decryption and decoding to the device hardwareor other trusted environment.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying drawings in which likereferences indicate similar elements, and in which:

FIG. 1 illustrates an example of an encrypted media stream;

FIG. 2 illustrates a system according to an embodiment of the presentinvention;

FIG. 3 illustrates an alternate system according to embodiments of thepresent invention; and

FIG. 4 is a flow chart illustrating an embodiment of the presentinvention.

DETAILED DESCRIPTION

Embodiments of the present invention provide a scheme for allowingsoftware access to navigational data in a decrypted media stream whileprotecting stream payloads. As used in this specification, the phrases“one embodiment” or “an embodiment” of the present invention means thata particular feature, structure or characteristic described inconnection with the embodiment is included in at least one embodiment ofthe present invention. Thus, the appearances of the phrases “in oneembodiment,” “according to one embodiment” or the like appearing invarious places throughout the specification are not necessarily allreferring to the same embodiment.

Additionally, reference in the specification to the term “device”,“machine” or “apparatus” may include any one of a number of processorbased computing devices, including but not limited to desktop computingdevices, portable computing devices (laptops as well as handhelds),set-top boxes, and game consoles. Handheld devices may include, but arenot limited to, personal digital assistants (PDAs), mobile internetdevices (MIDs), laptops, digital cameras, media players, ultra mobilepersonal computers (UMPCs) and/or any computing device that is capableof roaming on, and connecting to, a network. Finally, the term “openplatform” and “untrusted platform” may both refer to the same device andmay be used interchangeably throughout the specification.

In one embodiment of the invention, an open platform may rely on trusteddecryption of monolithically encrypted media streams to access theheader fields while still having no meaningful access to the mediapayloads. A “monolithically encrypted” media stream typically includes amedia stream wherein the payload and headers are encrypted together.This is in contrast with a “discretely encrypted” stream in whichportions of the stream may be encrypted separately from each other andfrom the unencrypted headers. For purposes of illustration, FIG. 1includes an example of a monolithically encrypted media stream. Asshown, each segment of Media Stream 100 may include Headers 105 (1−n)and Payloads 110 (1−n). The Headers and Payloads may be encrypted priorto transmission and as each segment (1−n) is received by an untrustedmedia player, the segment may be decrypted. In existing systems, bothPayloads 110 (1−n) and Headers 105 (1−n) would have to be decrypted inorder to access the navigational information. Payloads 110 (1−n) maythereafter be vulnerable to attack.

In embodiments of the present invention, however, once decrypted, thenavigational headers may be available to software running on the mediaplayer while the decrypted payload remains secure. FIG. 2 illustrates anexample of an open platform that receives Media Stream 100 according toembodiments of the present invention. Specifically, Open Platform 200comprises a media player module (“Media Player Module 205”) coupled toSource Filter 210. Source Filter 210 may be coupled to a securepartition. In one embodiment, the secure partition may include TrustedDecryption Module 215, which in turn may be coupled to Storage Device220. According to embodiments of the invention, Media Player Module mayrefer to a module capable of processing digital media. As such, MediaPlayer Module may be implemented in software, hardware, firmware or acombination thereof.

According to various embodiments of the invention, Trusted DecryptionModule 215 may include a Trusted Platform Module (“TPM”), IntelCorporation's Active Management Technologies (“AMT”) and/or Intel's“Manageability Engine” (“ME”) and/or other comparable or similartechnologies. In one embodiment, Trusted Decryption Module 215 includesthe capability to decrypt monolithically encrypted media streams and tostore the resulting media data in Storage Device 220. According toembodiments of the present invention, Storage Device 220 is accessibleby Trusted Decryption Module 215 via Source Filter 210 but notaccessible by other software that may be running on Open Platform 200.Storage Device 220 may additionally be accessible by other trustedcomponents on Open Platform 200, such as Trusted Graphics Rendering Unit225 to process Payloads 110 (1−n). Although Trusted Graphics RenderingUnit 225 is illustrated herein, it is not a component necessary forembodiments of the present invention to function.

To further facilitate understanding of embodiments of the presentinvention, the following describes an example of how Open Platform 200may handle an incoming monolithically encrypted media stream. Uponencountering Media Stream 100, Open Platform 200 may invoke SourceFilter 210 to preprocess Media Stream 100. In one embodiment, SourceFilter 210 may pass the Media Stream 100 or a portion of Media Stream100 to Trusted Decryption Module 215. Trusted Decryption Module 215 maythen decrypt Media Stream 100, restoring Headers 105 (1−n) and Payloads110 (1−n).

In one embodiment, Trusted Decryption Module 215 may not include anyintelligence to understand the type of media stream data it decrypts. Inorder to ensure that the media type is as expected, in one anembodiment, Source Filter 210 may send Header-Match Pattern 230 andHeader-Match Mask 235 to Trusted Decryption Module 215, together withMedia Stream 100. Source Filter 210 may additionally send otherinformation, including encryption algorithm properties to TrustedDecryption Module 215. As described in further detail below, TrustedDecryption Module 215 may utilize the encryption algorithm properties todecrypt the media stream and then utilize Header-Match Pattern 230 andHeader-Match Mask 235 to derive additional information about the stream.Based on the entire set of information available to

Trusted Decryption Module 215, it may then determine whether thedecrypted media stream may be accessed.

As discussed above, Trusted Decryption Module 215 may not includeintelligence to determine the type of media stream it receives fromSource Filter 210. Instead, Source Filter 210 may identify the mediatype and send the appropriate Header-Match Pattern 230 and Header-MatchMask 235 to Trusted Decryption Module 215. Trusted Decryption Module 215may utilize Header-Match Pattern 230 and Header-Match Mask 235 todetermine whether the expected navigation headers for the media type aremet. If the decrypted headers match Header-Match Patten 230 andHeader-Match Mask 235, Trusted Platform Module 215 may then—enable atrusted component on the platform to render the content. Thus, forexample, on a platform having Trusted Graphics Rendering Unit 225,Trusted Platform Module 215 may enable Trusted Graphics Rendering Unit225 to utilize decrypted Headers 110 (1−n) to navigate to decryptedPayload 105 (1−n) in Storage Device 215 and render the content. Thedecrypted Payload 105 (1−n) thus remains secure and inaccessible tocomponents other than the trusted components on the platform. Once theheaders are verified, they may be utilized by the untrusted componentsto navigate to the decrypted Payload 105(I-n) and render the payloadwithout exposing the payload to untrusted components.

In one embodiment of the invention, Header-Match Pattern 230 includes adescription of the expected pattern of bits that a media header forMedia Stream 100 may match. The length of Header-Match Pattern 230pattern may be bounded. Additionally, Header-Match Mask 235 may includea pattern of bits that may be ignored (so-called “don't care bits”)because some bits may vary from header to header. In one embodiment, thenumber of “don't care” bits in Header-Match Mask 235 relative to thepattern length of Header-Match Pattern 230 may be utilized to determinewhether to retrieve any of Media Stream 100 from Trusted DecryptionModule 215. Thus, for example, Open Platform 200 may be configured suchthat if Header-Match Pattern 230 is too long or the number of “don'tcare” bits in Header-Match Mask 235 is too high, Trusted DecryptionModule 215 may identify that combination of values as vulnerable toexposing payload data, return an error and not respond to subsequentretrieval requests. Source Filter 210 may provide the error appropriateto the underlying media stream format of Media Stream 225.

In alternate embodiments, Trusted Decryption Module 210 may comprisesecure software or virtual partitions such as a secure and isolatedvirtual machine or Intel Corporation's Secure Enclave technology. FIG. 3is an example of a virtualized platform according to an embodiment ofthe present invention. Specifically, as illustrated, Open Platform 300may include a virtual-machine monitor (“VMM 305”) that presents anabstraction of the platform (“virtual machines” or “VMs”) to othersoftware on the platform. Although only two VM partitions areillustrated (310 and 320), these VMs are merely illustrative and anynumber of virtual machines may be configured on the host. VMM 305 may beimplemented in software (e.g., as a standalone program and/or acomponent of a host operating system), hardware, firmware and/or anycombination thereof

Each VM may function as self-contained platforms respectively, runningtheir own “pest operating systems” (illustrated as “Guest OS” 325 and330) and other software (illustrated as “Guest Software” 335 and 340).Each Guest OS and/or Guest Software operates as if it were running on adedicated computer rather than a virtual machine. In reality, VMM 305has ultimate control over the events and hardware resources andallocates resources to the VMs according to its own policies.

According to embodiments of the present invention, one of the VMs mayinclude trusted decryption software and be designated a secure andisolated security partition (the secure partition illustrated as “SecureVM 310”). Secure VM 310 may include Trusted Decryption Module 210, aswell as Trusted Graphics Rendering Unit 225. Trusted Decryption Module210 and Trusted Graphics Rendering Unit 225 may access Payload 110 (1−n)in Storage Device 345. VM 320, on the other hand, may be accessible to auser and include components such as Source Filter 350 and Media PlayerModule 355.

Upon detecting the media stream encryption in VM 320, Source Filter 350may be invoked to preprocess Media Stream 100. In one embodiment, SourceFilter 350 in VM 320 may pass Media Stream 100 or a portion of MediaStream 100 to Trusted Decryption Module 215 in Secure VM 310. TrustedDecryption Module 215 may then decrypt Media Stream 100, restoringHeaders 105 (1−n) and Payloads 110 (1−n). Source Filter 350 mayadditionally send encryption algorithm properties, Header-Match Pattern230 and Header-Match Mask 235 to Trusted Decryption Module 215, togetherwith Media Stream 100. In one embodiment, Trusted Decryption Module 215may utilize the encryption algorithm properties to decrypt the mediastream and then utilize Header-Match Pattern 230 and Header-Match Mask235 to derive additional information about the stream, as described indetail above. Based on the entire set of information available toTrusted Decryption Module 215, it may then determine whether thedecrypted media stream may be accessed.

In one embodiment, if the decrypted media stream is deemed to beaccessible to VM 320, Trusted Platform Module 215 may enable TrustedGraphics Rendering Unit 225 to utilize decrypted Headers 110 (1−n) tonavigate to decrypted Payload 105 (1−n) in Storage Device 345 and MediaPlayer Module 355 may then render the content in VM 320. As illustrated,VM 320 may not directly access payload 110 (1−n) or Storage Device 345.Payload 105 (1−n) thus remains secure and inaccessible to partitionsother than Secure VM 310.

FIG. 4 is a flow chart illustrating one embodiment of the presentinvention. Although the following operations may be described as asequential process, many of the operations may in fact be performed inparallel and/or concurrently. In addition, one or more embodiments, theorder of the operations may be re-arranged without departing from thespirit of embodiments of the invention. At 401, an open platform mayreceive a monolithically encrypted media stream comprising navigationalheaders and payloads. A source filter may identify the media type in402, and recognize that the media is monolithically encrypted, at 403.The source filter may then send the encrypted media stream to a trustedcomponent on the platform 404. In 405, the source filter may also send aheader matching pattern and a header matching mask to the trustedcomponent, suitable for the media type identified in 402.

Upon receipt of the monolithically encrypted media stream, the headermatch pattern and the header matching mask, the trusted component maydecrypt the media stream into unencrypted headers and payloads in 406.The trusted component may thereafter determine whether the headermatches the header match pattern and header match mask in 407. In 408,if the header matches, the trusted component may enable other trustedcomponents to utilize the decrypted headers to access the decryptedpayloads from the secure storage. If, however, the header does notmatch, the trusted component in 409 may refuse to fulfill any requestsfor the payload.

The scheme according to embodiments of the present invention may beimplemented on a variety of computing devices. According to anembodiment, a computing device may include various other well-knowncomponents such as one or more processors which can be specializedReduced Instruction Set Computer (RISC) engines or general purposeprocessing engines. The processor(s) and machine-accessible media may becommunicatively coupled using a bridge/memory controller, and theprocessor may be capable of executing instructions stored in themachine-accessible media. The bridge/memory controller may be coupled toa graphics controller, and the graphics controller may control theoutput of display data on a display device. The bridge/memory controllermay be coupled to one or more buses. One or more of these elements maybe integrated together with the processor on a single package or usingmultiple packages or dies. A host bus controller such as a UniversalSerial Bus (“USB”) host controller may be coupled to the bus(es) and aplurality of devices may be coupled to the USB. For example, user inputdevices such as a keyboard and mouse may be included in the computingdevice for providing input data. In alternate embodiments, the host buscontroller may be compatible with various other interconnect standardsincluding Ethernet, Gigabit Ethernet, PC1, PCI Express, FireWire andother such existing and future standards.

In the foregoing specification, the invention has been described withreference to specific exemplary embodiments thereof. It will, however,be appreciated that various modifications and changes may be madethereto without departing from the broader spirit and scope of theinvention as set forth in the appended claims. The specification anddrawings are, accordingly, to be regarded in an illustrative rather thana restrictive sense.

1. A method, comprising: receiving, by a source filter of a computing device, a monolithically encrypted media stream; identifying, by the source filter, a media type of the monolithically encrypted media stream and header parameters associated with the media type; and providing, by the source filter, to a trusted decryption module, the monolithically encrypted media stream with the header-match pattern and the header-match mask, to decrypt the media stream, wherein the header-match pattern contains a description of an expected pattern of bits in a header of the media stream, and wherein the header-match mask contains a pattern of bits to be ignored if present in the header of the media stream.
 2. The method of claim 1, further comprising: receiving, by the trusted decryption module operating in a secure partition of the computing device, the monolithically encrypted media stream with the header-match pattern and be header-match mask; decrypting the media stream, by the trusted decryption module, to derive decrypted header data and decrypted payload data; and conditionally storing the decrypted payload data, in a secure data storage accessible to a trusted component, if the decrypted header matches the header-match pattern and the header-match mask.
 3. The method of claim 2, further comprising: enabling, by the trusted decryption module, the trusted component to navigate to the decrypted payload data stored in the secure data storage.
 4. The method of claim 3, wherein the trusted component includes a trusted graphics processing unit.
 5. The method of claim 3, wherein navigating to the decrypted payload data stored in the secure data storage includes: retrieving the decrypted payload data; and processing the payload data according to the media type of the media stream.
 6. The method of claim 5, wherein: the media type is graphics; the secure trusted component comprises a trusted graphics processing unit; and processing the payload data according to the media type of the media stream includes processing the decrypted payload to render and display graphics of the media stream.
 7. The method of claim 2, wherein the secure partition comprises one of a Trusted Platform Module (TPM), a Management Engine (ME) or an Active Management Technologies (AMT) partition.
 8. The method of claim 2, wherein the secure partition includes a virtual partition running on a virtualized host.
 9. An apparatus, comprising: a source filter module to receive a monolithically encrypted media stream, identify a media type of the monolithically encrypted media stream and header parameters associated with the media type, and output the encrypted media stream with a header-match pattern and a header-match mask, wherein the header-match pattern contains a description of an expected pattern of bits in a header of the media stream, and wherein the header-match mask contains a pattern of bits to be ignored if present in the header of the media stream; and a trusted decryption module in a secure partition, coupled with the source filter module, to receive and decrypt the media stream in the secure partition to derive decrypted header data and decrypted payload data.
 10. The apparatus of claim 9, further comprising: a secure data storage module, coupled to the trusted decryption unit, to enable the trusted decryption unit to conditionally store the decrypted payload data in the secure data storage module if the decrypted header matches the header-match pattern and the header-match mask.
 11. The apparatus of claim 10, wherein the trusted decryption module is further to enable a trusted component to navigate to the decrypted payload data stored in the secure data storage.
 12. The apparatus of claim 11, wherein the trusted component includes a trusted graphics processing unit.
 13. The apparatus of claim 11, wherein navigate to the decrypted payload data stored in the secure data storage module includes: retrieve the decrypted payload data; and process the decrypted payload data according to the media type.
 14. The apparatus of claim 13, wherein: the media type is graphics; the trusted component comprises a trusted graphics processing unit; and the trusted graphics processing unit is to process the decrypted payload according to the media type and to render and display graphics in the media stream.
 15. The apparatus of claim 10, wherein the secure partition is one of a Trusted Platform Module (TPM), a Management Engine (ME) or an Active Management Technologies (AMT) partition.
 16. The apparatus of claim 10, wherein the secure partition includes a virtual partition running on a virtualized host.
 17. The apparatus of claim 10, further comprising: a media player module to play the media stream with assistance from the trusted component in accessing the decrypted payload data stored in the secure storage.
 18. At least one non-transitory machine accessible medium having stored thereon instructions that, when executed by one or more processing devices of a machine, cause the machine to provide a source filter to: receive a monolithically encrypted media stream; identify a media type of the monolithically encrypted media stream and header parameters associated with the media type; and pass the encrypted media stream to a trusted decryption module with the header-match pattern and the header-match mask, wherein the header-match pattern contains a description of an expected pattern of bits in a header of the media stream, and wherein the header-match mask contains a pattern of bits to be ignored if present in the header of the media stream.
 19. The at least one non-transitory machine accessible medium of claim 18, wherein the instructions, when executed by the one or more processing devices of the machine, further cause the machine to provide the trusted decryption module, in a secure partition, to: receive the encrypted media stream with the header-match pattern and the header-match mask; decrypt the media stream in the secure partition to derive decrypted header data and decrypted payload data; and conditionally store the decrypted payload data, in a secure data storage accessible to a trusted component, if the decrypted header matches the header-match pattern and the header-match mask.
 20. The at least one non-transitory machine accessible medium of claim 19, wherein the trusted encryption module is further configured to enable the trusted component to navigate to the decrypted payload data stored in the secure data storage.
 21. The at least one non-transitory machine accessible medium of claim 19, wherein the trusted component comprises a trusted graphics processing unit.
 22. The at least one non-transitory machine accessible medium of claim 19, wherein navigate to the decrypted payload data stored in the secure data storage includes: retrieve the decrypted payload data; and process the decrypted payload data according to the media type.
 23. The at least one non-transitory machine accessible medium of claim 22, wherein: the media type is graphics; the trusted component comprises a trusted graphics processing unit; and the trusted graphics processing unit is to process the decrypted payload according to media type and to render and display graphics of the media stream.
 24. The at least one non-transitory machine accessible medium of claim 18, wherein the secure partition comprises one of a Trusted Platform Module (TPM), a Management Engine (ME) or an Active Management Technologies (AMT) partition.
 25. The at least one non-transitory machine accessible medium of claim 18, wherein the secure partition includes a virtual partition running on a virtualized host. 